This invention relates generally to reducing down-time during software replacement and more particularly to the automatic dynamic updating of software.
Software components will need updating many times throughout their lifecycle. New versions of the software may be needed to repair bugs or to upgrade to an enhanced version of the software. Updating often results in downtime. As systems become more complex and software users become more dependent on a running system, downtime will become less and less acceptable.
For most software systems an update is performed by halting the system and installing the new version. Access to the software is unavailable during the upgrade. For many situations this is sufficient and only causes a minor inconvenience to a user of the software. In other situations the resulting delays are of greater inconvenience or even unacceptable.
Even if software can be upgraded on a system while it is running, most applications cannot take advantage of the updated software until the application is restarted, once again causing an inconvenience to a user.
Several systems have been developed to update software while the system is running. This ability is known by several names such as "on-line replacement" of software, updating software "on the fly", or "hot patching" software.
There are several known systems for updating software on the fly. One frequent drawback of known methods is the impact on the software applications. Software applications, in these methods, must be written so as to anticipate changes to the software components they use. If they are not written to anticipate the changes, then the entire program must be updated.
Current methods for on-the-fly replacement of software replace the software component at various levels of granularity. Some require the entire software program be replaced while others allow for much smaller units such a procedure or a module. Known methods are summarized in M. Segal and O. Frieder, "On-the-fly Program Modification: Systems for Dynamic Updating", IEEE Software, pages 53-65, vol. 10, no. 2, March 1993.
Libraries
The software components used by software applications are often found in software libraries, a group of software routines collected together, usually for a related purpose. The purpose of the library can be said to be the library's "service". Software libraries are made available to a software application through the use of a linker. A linker has the task of combining a series of independently compiled or assembled program routines into a single module (the executable program). Libraries are incorporated into the executable program by one of two linking methods: a library can either be statically linked or dynamically linked to the application. When a library is statically linked, the library in made part of the executable program during the link. Therefore any modifications to a statically linked library would require a new executable program to be built by the linker.
A dynamically linked library exists, on the other hand, outside of the executable program. At link time the linker must know all of the external references of a library, such as the names of the routines available, but does not need to know the actual contents of the library itself, or even its location. It is not until run-time that the program must be able to determine the location of the library. Determining the location of the library at runtime is known as "runtime binding". Therefore a dynamically linked library is free to change everything except its interface definition up until the time it is executed.
Dynamic linking, however, does not, by itself, provide true dynamic updating. It does not allow for changing a reference to an external procedure during a run after the references have been established. The binding takes place at or before the first time a procedure is invoked. Subsequent references are not typically rebound. Even if the external reference is resolved every time the external procedure is called, dynamic linking is ineffective because it does not allow for replacing a software component while that component is being executed. Also, changing libraries by dynamic linking does not keep track of the "state" of the library from the old version to the new version. When the new version is in place, it does not know the state of the library data structures or other state data that the old version had created. This will lead to an update that is unreliable to the user.
Therefore, there is a need for a system and method for replacing software components during a running process without significantly impacting the process.
Further, there is a need for a system and method for doing so that does not require changes to the software application using the replaceable software component.
Existing solutions do not replace software at the level of software libraries, and therefore do not take advantage of the built in dynamic linking capability found in many modern operating systems, such as Multics, HP/Apollo's Aegis, Sun Microsystems'SunOS 4.0, Microsoft's NT or Windows and HP's HP-UX system.